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SYSTEM AND METHOD FOR DETECTING AND HANDLING COMMUNICATION 

BASED ERRORS IN A WIRELESS TRANSACTION SYSTEM 
The present application claims priority from Canadian paieni application No. 2,330,017, 
The present invention relates to the field of wireless electronic transaction systems, and 
5 more particularly to a method for accurately reflecting states between a wireless client 
and server, where an extension of the server-side state is held within a wireless device in 
volatile memory. 

BACKGROUND OF THE INVENTION 
10 Point of sale (POS) systems have become almost universally adopted by merchanis. 

While most POS systems are deployed at a merchant's premises, a wireless POS system 
ll^ has mobile terminals that allows electronic payment to be made other than at the 

merchant premises. This has created new business opportunities for existing merchants, 

while spawning new business ventures. For example, huemet shopping with ''payment at 
Ul 15 the door*' opens new marketing channels with increased sales. We are all familiar with 
Q the delivery of groceries, pizza and other food stufis ordemi from a vendor by telephone 

or the Internet and delivered to the customer's home where payment by, credit or debit 

card is approved using a remote handheld POS terminal. 

U 20 A wireless POS system typically comprises one or more wireless POS terminals 
connected via a wireless network through a gateway to a financial transaction server 
(FTS), which is typically the merchant's bank or processor operating on behalf of the 
merchant's bank, often referred to as the acquiring bank. One of the benefits of these 
wireless POS systems is that the customer is not always required to have cash on hand. 
25 Further, the POS system is normally integrated with the merchant's payment transaction 
server and allows various electronic reconciliation of the merchant's bank account with 
that of the financial institution (FI) and reduces the amount of paperwork for ^e 
merchant. 

30 One of the disadvantages, however, of the traditional wireless POS terminal is that it is 
relatively expensive, runs a proprietary protocol and has to be obtained from one of a 
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limited number of suppliers. These special POS terminals were developed out of 
necessity to ensure reliable and trusted connrnmication between the POS terminal and the 
FTS and more importantly, to provide the customer with a degree of confidence that the 
exchange has been transacted with a legitimate merchant. 

5 

One solution in order to lower the cost of traditional POS systems is to utilize, instead of 
dedicated POS terminals, die use of inexpensive wireless devices, such as cellular 
telephones, PDAs and similar personal trusted devices. Some of the benefits of such 
devices are that they are inexpensive and are capable of operating over the relatively 
10 inexpensive wireless Internet infrastructure. Typically, these devices communicate using 
an open global standard for wireless Internet transmission such as the Wireless 
Application Protocol (WaP). 

WAP devices include a WAP microbrowscr to interact with servCT-side WAP/Web 
4f applications. The HTTP protocol is used for passing data in the form of pages between 

Q. the microbrowser on the wireless device and the Web aj^hcatioiu The stateless nature of 
:J . Hyper-TexT Transfer Protocol (HTTP) is a disadvantage of any Y?eb appUcation that runs 

on a server computer connected to a network and which uses HTTP to conununicate with 

cliem web browsers. This is because the HTTP protocol is generally a stateless 
"^^^ 20 request/response protocol. That is, for every request generated by a user, die web 

appUcation provides a response, which typically includes one or more variables used by 

the application to identify the user and/or the session. 

WAP/Web applications basically follow a client / server communications model in which 
25 the client (microbrowser) is not required to maintain state information- The state is 
typically held within the server-side business logic of an application server. 
This ^statelessness' of the microbrowser within wireless devices poses a problem for 
some applications as for example in financial transactions like POS transactions, POS 
transactions tend to require a sequence of steps or states at the server before the 
30 transaction is completed. For example, in a wireless cash transaction, the user sends a 
request to a merchant payment application running on the webserver, which in turn 
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forwards the request to a FI for appxoval. The response from the FI is sent to the 
payment application, which in turn forwards the response to the user. Thus the server 
srate needs to be accurately reflected to the user of the POS device to avoid any out of 
balance conditions between the user, merchant and the FI. 

5 

Consequently there is a need for the server to detect duplicate messages from a mobile 
device or detect a possible undelivered message from a mobile device. Furthermore in the 
case of incomplete transactions there is a need to implement reversals to avoid, in the 
specific case of financial transactions, out of balance situations at the FI or processor. 

10 

SUMMARY OF THE INVENTION 

The present invention seeks to provide a solution to the problem of extending a server-side 
state machine to stateless microbrowser based devices over inherently unstable wireless networks. 

' : 15 in accordance with this invention there is provided a data processing method for handling of 
.1 errors in communication benveen a wireless device and a server in a wireless transaction 

processing system, the method comprising the steps of; 
^ creating, within persistent storage, a n^saction log containing recovery information, 

: y which can be used for recovery from errors in communication during a transaction; 

20 retrieving, from the transaction log, said recovery information relating to a current 
transaction; 

comparing said reoieved information to error correction information received from said 
wireless device; 

determining whether the received error correction information meets at least one 
25 predetermined criterion; and 

performing an error handling process if the received error correction information meets 
the predetermined criterion. 

An advantage of the present system is the ability to detect duplicate messages from a 
30 wireless device. 



3 



DEC-31-20P1 11:29 FROM-Fasken Marti neau OuMoul in LLP 416-364-7813 T-58B P. 007/023 F-353 

A fiinher advantage is the ability to detea a possible undeUvered message from a 
wireless device, 

A still further advantage is the ability, in the case of incomplete transactions, to 
5 implement error recovery, such as reversals to avoid, in the specific case of financial 
transactions, out of balance situations at the FI or processor. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 Figure 1 is a schematic diagram of a wireless transaction system according to an 
embodiment of the invention; 

Figure 2 is a flow diagram showing an ermr detection process according to an 
:rd embodiment of the present invention; and 

Ul Figures 3, 4 and 5 are ladder diagranas showing a message exchange sequence in the 

15 system of figure 1. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

ul In the following, like numerals refer to like structures in the drawings. 

20 

Referring to Figure 1, there is illustrated a general representation of the manner for using 
a personal trusted device (PTD) such as a mobile terminal ui wireless transaction system 
according to an embodiment of the present invention. The system 100 preferably 
includes at least one WAP (or some other type of mobile internet protocol) enabled 

25 device 110 such as a cell phone, alternatively, the PTD could be a laptop computer, 
personal data assistant, pager or another mobile electronic device. The WAP device 
normally connects via a WAP proxy or gateway 112 to a web server 114. The WAP 
gateway provides for the ability of a wireless device such as ihc mobile electronic 
transaction device 110 to access the Internet using the WAP protocol. The WAP gateway 

30 acts as a proxy between a wireless network and a wireline neiwoik. The WAP gateway 
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converts between the wireless toemet based on the WAP protocol and the wireline 
Internet based on the HTTP protocol. 

The web server 114 runs a payment application and in turn interacts with an application 

5 server 124. The payment application may be used to facilitate a fac^to-face transaction 
where the merchant or merchant representative and the consumer are together at the same 
place at the time of the transaction. The payment application may also be used to 
facilitate a non-face-to-face transaction where the merchant and the consumer are not 
together at the same place at the time of The transaction. Such a non face-to-face 

10 transaction is typical of a consumer making a bill payment for post paid cellular 
telephone air time for example or for making payments into a prepaid account for cellular 
air lime. This example is also the case where the cellular telephone carrier is not flic 
merchant selling goods and services such as air time, but also where the cellular carrier is 
is simply enabling other merchants to sell their goods and services to cellular carrier 

15 subscribers via pre-pay, post pay or payment aggregation servdces. The application 
server iacludes business logic for processing the various transaction requests from the 
web server payment application and forwards them to the financial institution (FI). The 
application server also receives responses from the financial institution and forwards 
transaction completion notifications and responses to the consumer and to the merchant 

20 system via the web server payment applicadou. 

As may be seen in figure 1» the application server may optionally be coupled via a 
nerwork to a transaction gateway server (TGS) 118. Such a TGS is described in pending 
U.S, patent application No. 09/559,278 incorporated herein by reference. The TGS 

25 connects via a proprietary or dedicated network or other similar network to at least one 
financial transaction server (FTS) or payment gateway 120. In addition, the system 100 
may also include an enterprise reporting subsystem (ERS), which is connected to die 
server 116 for receiving wireless POS transaction information. The ERS also receives 
information from the clerk or merchant firom its POS terminals and possibly the WAP 

30 devices. 
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In general however the specific details of transaciion processing are not necessary to an 
imderstanding of the present invention and wiU not be discussed further. 

A WAP application 123 is a set of files residing within the payment application 122, 
5 which represents the application that has a user interface presented via a number of pages 
on a WAP enabled device. The application is downloaded to the mobile device as a set 
of wireless markup language (WML) display pages or cards in a deck, each card or page 
representing one screen of information. Intermediate calculations such as totaling, tax 
calculations, coupon calculations are performed within script files, which are also 
10 downloaded to the mobile device, Dynanuc content needed for the mobile device is 
generated from a set of Java Servlets and Java Server Pages (JSP) within the web server. 

iJJl As mentioned earlier during a transactions the user sends a request to the merchant 
J payment application ruxming on the webserver, which in turn forwards the request to a Fl 

III 15 for approval. The response fix>m the Fl is sent to the payment application, which in mm 
^ forwards the response to the user. If for whatever reason the commtmication between the 

wireless device and the server breakdown^ then an out of balance situation is likely to 
fii occur. 

u;l 20 The present invention solves this problem by including a sequence number with the 
messages transmitted during a transaction. In its most basic form the wireless device 
includes storage for the sequence number. This sequence number is synchronized with 
the sequence number expected by the business lo^c contained within the application 
server. The business logic is responsible for generating, verifying, and storing sequence 
25 numbers in a manner to be described below. 

Referring to figure 2, there is shown a flow diagram of a general data processing method 
executed by the business logic at the application server for handling of errors in 
communication between the wireless device and the payment application server in die 
30 wireless transaction processing system. The application server creates, within persistent 
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Storage, a transaction log containing recovery information, which can be used for 
recovery from errors in communication during a transaction. 

The manner of using the system 100 may be described as follows. The wireless device 
5 110 sends a transaction request including a prestored sequence number to the application 
server. For each transaction request received by the application server business logic, the 
application server processes the request. Once the transaaion request has been processed 
successfiiUy, the transaction is given a status of Pending Persistent Reversal (PPR). This 
status is necessary, as the application server business logic cannot determine if the mobile 
10 device has received its response that the transaction has been processed successfiilly until 
the next request is received from the mobile device. The business logic attaches the next 
sequence number expected by the mobile device on the outgoing response message. The 
payment application 122 at the web server keeps this sequence number and includes it as 
a hidden field on the next set of user interface cards downloaded to the device 110, The 
1 5 next request received from the mobile device can be one of three possibilities: the proper 
sequence number is sent, ttie previous sequence number is sent wifli a duplicate of the 
previous request, or the previous sequence number is sent with a different request. 

The business logic has to wait for the sequence number of the next incoming request 
20 from the mobile device. The business logic will either set the stams of the previous 
transaction to completed, or the business logic will reverse the previous transaction. 
Each of these scenarios is described below in the context of a TGS. 

Referring to figure 3 ihere is shown a ladder diagram of an exchange of messages in a 
25 transaction system according to an embodiment of the present invention. 



1. A request is sent from the WAP device with sequence number 1 and is received 
by the payment application. 

2. The payment application forwards the request with sequence number 1 to the 
3 0 application server business logic. 
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3. The application server business logic sends the request to the TGS as an MTCP 

message. 

4. The TGS processes ihe transaction by sending the request to the FL 

5. The Fl sends Che response to The TGS. 

5 6. The TGS sends the response to the application server busriness logic in the form of 
an MTCP response message. 
7, The applicaxion server business logic detennines the next sequence number as 2, 
The response of the transaction along with the next sequence number is sent to the 
payment application in the web server. 
10 8, The status of the transaction is set to Pending Persistent Reversal. 

9. The response is displayed on the mobile device. 

10. Onoe die user of the mobile device attempts die next transaction, the payment 
^plication retrieves the sequence number and sends the next user interface 
(WML deck) for fliis transaction along with the sequence number 2 to the mobile 

15 device. 

11. The user initiates a new transaction which is sent from the device with sequence 
number 2 to the payment application. 

12. The payment application forwards die request with sequence number 2 to the 
application server business logic, 

20 13. The business logic determines that the request contains the next sequence number 

and sets the status of the previous transaction to completed and removes the PPR 
status. 

14. The next transaction is processed and steps 3 to 9 are repeated. 

25 Referring to figure 4 there is shown a ladder diagram of an exchange of messages in a 
transaction system, when a message is lost, according to an embodiment of the present 
invention. 

1. A request is sent fiiom the WAP device with sequence number 1 and is 
30 received by the payment application- 
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2, The payment application forwards the request with sequence number 1 to the 
application server business logic. 

3. The application server business logic sends the request to the TGS as an 
MTCP message. 

5 4, The TOS processes the transaction by sending the request to the FL 

5. The H sends the response to the TGS . 

6. The TGS sends the response to the application server business logic in the 
form of an MTCP response message. 

7. The application server business logic determines the next sequence nnmber as 
10 2, The response of the transaction along with the next sequence number is 

sent to the payment application in the web server. 

8. The status of the transaction is set to Pending Persistent Reversal, 

9. The response cannot be displayed on the mobile device, as the message has 
been lost either on the downlink between the web payment application and the 

15 WaP gateway or on the downlink between the WAP gateway and the mobile 

device. 

10. The user docs not see the response and attempts to resend the transaction. The 
transaction request is seat with sequence number 1 to the payment application. 

11. The payment apphcatioa forwards the request with sequence number 1 to the 
20 application server business logic. 

12. The business logic determines an identical request has been received. Since 
the business logic stores the response of the previous transaction, the response 
is sent back to the payment application with sequence number 2, 

13. The mobile device receives the response. 

25 



Referring to figure 5 there is shown a ladder diagram of an exchange of messages 
in a transaction system according to an embodiment of the present invention. 
1. A request is sent from the WAP device with sequence number 1 and is 
30 received by the payment application. 
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2. The payment application forwards the request with sequence number I to the 
application server business logic. 

3. The application server business logic sends the request to the TGS as an 
MTCP message, 

5 4. The TGS processes the transaction by sending the request lo the FL 

5. The FI sends the response to the TGS. 

6, The TGS sends the response to ttie application server business logic in the 
form of an MTCP response message, 

7. The application server business logic determines the next sequence number as 
10 2. The response of the transaction along with the next sequence number is 

sent to Ae payment application in the web server. 

8. The status of the transaction is set to Pending Persistent Reversal. 

9, The response cannot be displayed on the mobile device, as the message has 
been lost either on the downlink between the web payment application and die 

1 5 WAP gateway or on the downlink between the WAP gateway and the mobile 

device. 

10, The user does not see the response and anempts to resend the transaction. 
However, the user chooses to change some of the fields before resubmitting 
the request. The modified transaction request is sent with sequence number 1 

20 to the payment application, 

1 L The payment application forwards the request with sequence number I to the 

application server business logic. 
12, The business logic determines a different transaction has been received with 
sequence number 1 . In this case, the business logic determines that previous 
25 transaction has been lost and attempts to perform a reversal on the previous 

transaction. 

13- Once the reversal request has been processed successfully, the application 
server business logic sends the modified transaction request to the TGS as an 
MTCP message. 

30 14. The TGS processes the transaction by sending the request to the FI, 

15. The FI sends the response to the TGS. 
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16. The TQS sends the response lo ihe application server business logic in the 
form of an MTCP response message. 

17. The application server business logic deiennines the next sequence number as 
2. The response of the transaction along with the next sequence number is 

5 sent to ihe payment application in the web tier. 

18. The status of the transaction is set to Pending Persistent Reversal- 

19. The response is displayed on the mobile device, 

Accordingly, it may be seen that the present invention provides an efficient solution to 
1 0 the problem of extending a server-side state machine to stateless tnicro-browser based devices. 
While die invention has been described in connection with a specific embodiment thereof 
and in a specific use, various modifications thereof will occur to those skilled in the art 
without departing from the spirit of the invention. 

■=y 15 The terms and expressions which have been employed in the specification are used as 
Q terms of description and not of limitations, there is no intention in the use of such terms 

and expressions to exclude any equivalents of the features shown and described or 
portions thereof but it is recognized that various modifications are possible within the 
ul scope of the invention. 
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